View CA91C142_1216328.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

www.tundra.com universe ii (CA91C142) debug and initialization notes
the information in this document is subject to change without notice and should not be construed as a commitment by tundra semiconductor corporation. while reasonable precautions have been taken, tundra semiconductor corporation assumes no responsibility for any errors that may appear in this document. no part of this document may be copied or reproduced in any form or by any means without the prior written consent of tundra semiconductor corporation. tundra? products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the tundra product could create a situation where personal injury or death may occur. should buyer purchase or use tundra products for any such unintended or unauthorized application, buyer shall indemnify and hold tundra and its officers, employees, subsidiaries, affiliates and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that tundra was negligent regarding the design or manufacture of the part. the acceptance of this document will be construed as an acceptance of the foregoing conditions. product: universe ii (CA91C142) title: universe ii debug and initialization notes document: 8091142_an005_01 status: final copyright: may, 2001 tundra semiconductor corporation published in canada all rights reserved. tundra, tundra logo are registered trademarks of tundra semiconductor corporation. all other product and logo trademarks are the property of their respective companies.
universe ii debug and initialization notes 8091142_an005_01 iii revision history 8091142_an005_01, final, may 2001 this is the first version of this document.
universe ii debug and initialization notes 8091142_an005_01 iv contents overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 software and registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 generating pci configuration cycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
universe ii debug and initialization notes 8091142_an005_01 1 1. universe ii (CA91C142) debug and initialization notes this application note is intended to show common problems that may occur which can cause the universe ii not to operate as expected. the sections addressed in this design note include: ?hardware? on page 1 ?software and registers? on page 8 ?registers? on page 10 ?generating pci configuration cycles? on page 13 1.1 overview this application note is intended to show common problems that may occur whichwould cause the universe ii not to operate as expected. this application note is intended to be used as a guide only. this document isdivided into two sections hardware and software. each section outlines various issues within those areas which would cause the universe ii to not function as expected. as a reference, users may also wish to read the application note on fast initialization. (8091142_an003_xx) 1.2 hardware the following describes various hardware issues associated with the universe ii. note all references to the universe ii manual refer to the spring 1998 version (8091142.md300.01).
universe ii debug and initialization notes 8091142_an005_01 2 1.2.1 power up options the universe ii may be automatically configured at power-up to operate in different functional modes. these power-up options allow the universe ii to be set in a particular mode independent of any local intelligence. the universe ii power-up options are listed in table 1. the majority of the universe ii power-up options are loaded from the vmebus address and data lines after any pwrrst#. there are two power-up options that are not initiated by pwrrst#. the first of these is pci bus width (a power-up option required by the pci bus specification), this is loaded on any rst# event from the req64# pin. the second special power-up option is vmebus syscon enabling, required by the vmebus specification. the syscon option is loaded during a sysrst* event from the bg3in* signal. power up options are described in more detail in more detail in ?power-up option? on of the universe ii user?s manual. table 1: pin level for specific power up modes pin a level b power up mode register field va[31] low high vmebus register access disable vmebus register access enable vrai_ctl en va[30:29] low, low low, high high, low high, high vmebus address space a16 vmebus address space a24 vmebus address space a32 reserved vrai_ctl vas va[28:21] see table 2: vrai base address power-up options vrai_bs bs va[20] c low high pci bus memory space pci bus i/o space vcsr_ctl las[0] va[19:15] vmebus csr translation offset vcsr_to to vd[30] low high dy4 auto id disable dy4 auto id enable misc_stat dy4aut o vd[29] d low high no effect initiate vme64 auto id sequence misc_ctl v64aut o low high vme software interrupt masked vme software interrupt enabled vint_en sw_int low high vme software interrupt inactive vme software interrupt active vint_stat sw_int low high vmebus software interrupt destination 0 (masked) vmebus software interrupt destination virq*[2] vint_map1 sw_int vd[28] low high universe ii is not in bi-mode universe ii is in bi-mode misc_ctl bi
universe ii debug and initialization notes 8091142_an005_01 3 vd[27] low high assert vxsysfail e deassert vxsysfail after reset f vcsr_set sysfail vbgin[3]* low high universe ii is not vmebus system controller universe ii is vmebus system controller misc_ctl syscon va[1] low high pci_bs0 mapped to i/o, pci_bs1 mapped to memory pci_bs0 mapped to memory, pci_bs1 mapped to i/o pci_bs0, pci_bs1 space va[5:2] pci target image 0 bound address range[31:28] g lsio_bd bd va[9:6] pci target image 0 base address [31:28] f lsio_bs bs va[11:10] low, low low, high high, low high, high vmebus address space a16 vmebus address space a24 vmebus address space a32 reserved lsio_ctl vas va[12] low high destination is pci bus memory space destination is pci bus i/o space lsio_ctl las va[13] low high image disabled image enabled lsio_ctl en va[14] low high pci master disabled pci master enabled pci_csr bm req64# h low high 32 bit pci bus size 64 bit pci bus size misc_stat lclsize a. all power-up options are latched only at the rising-edge of pwrrst#. they are loaded when pwrrst#, sysrst* and rst# are negated. b. the default level for all pins in low due to internal pull-downs. c. the las field will enable the pci_csr register?s ms or ios field if the en field of the lsio_ctl register is set. d. pin va[29] determines whether v64auto id will be used and sets up required registers e. this power-up option is over-ridden if vme64 auto-id has been enabled. this option would be used when extensive on-board diagnostics need to be performed before release of sysfail*. after completion of diagnostics, sysfail* may be released through software or through initiation of the vme64 auto-id sequence if that mechanism is to be used. f. this power-up option is over-ridden if vme64 auto-id has been enabled. this option would be used when extensive on-board diagnostics need to be performed before release of sysfail*. after completion of diagnostics, sysfail* may be released through software or through initiation of the vme64 auto-id sequence if that mechanism is to be used. g. the lower bits ([27:12]) are set to 0 h. the pci bus size is loaded on any rst# event, as per the pci 2.1 specification table 1: pin level for specific power up modes pin a level b power up mode register field
universe ii debug and initialization notes 8091142_an005_01 4 1.2.2 test mode the universe ii has i/o capabilities that are specific to manufacturing test functions. these pins are not required in a non-manufacturing test setting. table 3 below shows how these pins should be terminated for normal operation. test mode is described in more detail ?auxiliary test modes? of the universe ii manual. 1.2.3 jtag the universe ii includes dedicated user-accessible test logic that is fully compatible with the ieee 1149.1 standard test access port (tap) and boundary scan architecture. this standard was developed by the test technology technical committee of ieee computer society and the joint test action group (jtag). the jtag pins are not required for normal operation, see table 4 for jtag pin connections for normal operating mode. table 2: vrai base address power-up options vrai_ctl: vas bs[31:24] bs[23:16] bs[15:12] a16 0 0 power-up option va[28:21] a24 0 power-up option va[28:21] 0 a32 power-up option va[28:21] 0 0 table 3: test mode pin settings for normal operation pin name pin value tmode[2] v ss tmode[1] v ss tmode[0] v ss pll_testsel v ss enid v ss pll_testout v ss voctl v ss
universe ii debug and initialization notes 8091142_an005_01 5 jtag is described in more detail ?jtag support? of the universe ii manual. 1.2.4 clocks 1.2.4.1 clk64 clk64 is a 64 mhz clock that is required by the universe ii in order to synchronize internal universe ii state machines and to produce the vmebus system clock (vsysclk) when the universe ii is system controller (syscon). this clock is specified to have a minimum 60-40 duty cycle (20%) with a maximum rise time of 5 ns. using a different frequency is not recommended as it will alter various internal timers and change some vme timing. 1.2.4.2 sysclk the universe ii provides a 16 mhz vmebus system clock (sysclk) derived from clk64 when configured as syscon. 1.2.4.3 lclk the pci clock provides timing for all transactions on the pci bus. pci signals are sampled on the rising edge of lclk, and all timing parameters are defined relative to this signal. the pci clock frequency of the universe ii must be between 25 and 33mhz. lower frequencies will result in invalid pci and vme timing. table 4: jtag pin connections for normal operating mode pin name pin value trst# v ss tck v dd tdi v dd tms v dd tdo v ss
universe ii debug and initialization notes 8091142_an005_01 6 1.2.5 resets 1.2.5.1 overview of reset support the universe ii provides a number of pins and registers for reset support. pin support is summarized in table 5. register support is summarized in table 7 software initialization summary. table 5: hardware reset mechanisms interface and direction pin name long name effects a a. a more detailed account of the effects of reset signals is provided in ?reset implementation cautions? in the universe ii user?s manual vmebus input vrsysrst# vmebus reset input asserts lrst# on the local bus, resets the universe ii, and reconfigures power-up options. vmebus output vxsysrst vmebus system reset universe ii output for sysrst* (resets the vmebus) pci input pwrrst# power-up reset resets the universe ii and reconfigures power-up options. rst# pci reset input resets the universe ii from the pci bus. vme_reset# vmebus reset initiator causes universe ii to assert vxsysrst pci output lrst# pci bus reset output resets pci resources jtag input trst# jtag test reset provides asynchronous initialization of the tap controller in the universe ii.
universe ii debug and initialization notes 8091142_an005_01 7 the universe ii can only be reset through hardware, software can only cause the universe ii to assert its reset outputs. in order to reset the universe ii through software, the universe ii reset outputs must be connected to the universe ii reset inputs. for example, the sw_lrst bit in the misc_ctl register, which asserts the lrst# output, which will not reset the universe ii itself unless lrst# is looped back to rst#. as described in ?reset implementation cautions? of the users manual, there are potential loopback configurations resulting in permanent reset. 1.2.5.2 universe ii reset circuitry for information on the reset circuitry and the effects of various reset events of the universe ii refer to the universe ii user?s manual. the manual is available on the tundra website at www.tundra.com. table 6: software reset mechanism register name type function misc_ctl sw_lrst w software pci reset 0=no effect, 1=initiate lrst# a read always returns 0. sw_sysrst w software vmebus sysreset 0=no effect, 1=initiate sysrst* a read always returns 0. vcsr_set reset r/w board reset reads: 0=lrst# not asserted, 1=lrst# asserted writes: 0=no effect, 1=assert lrst# sysfail r/w vmebus sysfail reads: 0=vxsysfail not asserted, 1=vxsysfail asserted writes:0=no effect, 1=assert vxsysfail vcsr_clr reset r/w board reset reads: 0=lrst# not asserted, 1=lrst# asserted writes: 0=no effect, 1=negate lrst# sysfail r/w vmebus sysfail reads: 0=vxsysfail not asserted, 1=vxsysfail asserted writes:0=no effect, 1=negate vxsysfail
universe ii debug and initialization notes 8091142_an005_01 8 1.3 software and registers the following describes various software and register issues that may cause the universe ii not to operate as expected. 1.3.1 software initialization summary the following describes various software issues for the programmer during initialization and while debugging. table 7: software initialization summary functional group register bit description pci memory map pci_csr bm master enable ms target memory enable ios target io enable pci_bs0 bs base address space pci bus address space pci_bs1 bs base address space pci bus address space vme memory map vcsr_bs - vmebus csr base address pci slave images lsx_ctl en image enable lsx_bs - base address lsx_bd - bound address lsx_to - translation offset vme slave images vsix_ctl en image enable vsix_bs - base address vsix_bd - bound address vsix_to - translation offset vme requests mast_ctl vrl vmebus request level vrm vmebus request mode vrel vmebus release mode
universe ii debug and initialization notes 8091142_an005_01 9 interrupts lint_en - pci interrupt enables lint_stat - pci interrupt status lint_map0 - pci interrupt map lint_map1 - pci interrupt map lint_map2 - pci interrupt map vint_en - vmebus interrupt enables vint_stat - vmebus interrupt status vint_map0 - vme interrupt map vint_map1 - vme interrupt map vint_map2 - vme interrupt map vint_stat - vme interrupt status statid - vme status/id output vx_statid - vme status/id input dma dctl l2v dma transfer direction dtbc - dma transfer byte count register dla - dma pci bus address dva - dma vme bus address dgcs go dma go bit chain dma direct or link list mode dcpp (linked list) - dma command packet pointer d_llue update dma link list update enable error logging l_cmderr l_stat pci error log status cmderr pci command error log laerr - pci address log v_amerr amerr vmebus am code error log v_stat vmebus error log status vaerr - vmebus address error log bi-mode misc_ctl engbi bi-mode bit table 7: software initialization summary functional group register bit description
universe ii debug and initialization notes 8091142_an005_01 10 1.3.2 registers the following will describe in greater detail those registers shown in table 7 on page 8. for more information concerning these registers see the universe ii user?s manual. 1.3.2.1 pci memory map 1.3.2.1.1 pci_csr the pci_csr register contains the pci configuration space control and status registers. the bm bit determines whether a vme slave image will respond to a request. the ms and ios bits determine whether the target io and memory are enabled. 1.3.2.1.2 pci_bsx the first registers that must be programmed in the universe ii are the pci_bs0 and pci_bs1 registers. these registers specifies the base address of the universe ii register space as seen from the pci bus. one of these two registers determines the mapping into i/o space and the other into memory, this is determined by the space bit set during power-up (see power-up options of the universe ii user manual). 1.3.2.2 vme memory map 1.3.2.2.1 vcsr_bs the vcsr_bs register determines the base address for register access to the universe ii on the vmebus. 1.3.2.3 images 1.3.2.3.1 pci slave images the following registers must be programmed for an image to function properly, and not overlap with each other or other cards: base address lsx_bs, bound address lsx_bd, and the translation offset lsx_to (this register may be ignored if no translation offset is desired) the last bit that should be programmed is the en bit in the lsx_ctl register, which enables the image. timers lmisc cwt coupled window timer vme arbiter misc_ctl varb vmebus arbitration mode varbto vmebus arbitration time-out sysfail vcsr_set sysfail vmebus sysfail table 7: software initialization summary functional group register bit description
universe ii debug and initialization notes 8091142_an005_01 11 1.3.2.3.2 vme slave images the following registers must be programmed for an image to function properly, and not overlap with each other or other cards: base address (vsix_bs), bound address (vsix_bd), and the translation offset (vsix_to) - this register may be ignored if no translation offset is desired. the last bit that should be programmed is the en bit in the vsix_ctl register, which enables the image. 1.3.2.3.3 vme requests the following bits in the mast_ctl register determine how the universe ii will request and release the vmebus: vrl, vrm, vrel. vrl determines on which request level the universe ii will request the bus, the default is level 3. vrm determines the request mode that the universe ii will use, the default is demand mode. vrel determines went the universe ii will release the bus, release when done or release on request, the default is release when done. 1.3.2.4 interrupts interrupts are enabled through the following registers: lint_en and vint_en. once enabled the interrupts should be mapped through lint_mapx and vint_mapx respectively. the status of interrupts can be determined from the lint_stat and vint_stat registers respectively. on the vmebus there are additional registers associated with interrupts: statid and vx_statid. the statid register is the value that the universe ii will return on an iack cycle and vx_statid is the status/id that was returned to the universe ii on an iack cycle (when the universe ii is acting as an interrupt handler). when software interrupt bits are set (in lint_en and vint_en) they will automatically cause an interrupt of the appropriate level to be generated. 1.3.2.5 dma transfers dma transfers can be programmed into two modes of operation: direct mode and link list mode. in direct mode the user must reprogram the source and destination address registers (dma, dla) before each transfer. these registers are not updated in direct mode. in linked-list mode, these registers are updated by the dma when (and only when) the dma is stopped, halted, or at the completion of processing a command packet. if read during dma activity, they will return the number of bytes remaining to transfer on the pci side. all of the dma registers are locked against any changes by the user while the dma is active. the source and destination addresses for the dma reside in two registers: the dma pci bus address register (dla register), and the dma vmebus address register (dva register). the determination of which is the source address, and which is the destination is made by the l2v bit in the dctl register. when set, the dma transfers data from the pci to the vmebus. when cleared, the dma transfers data from the vmebus to pci bus and dla becomes the pci destination register.
universe ii debug and initialization notes 8091142_an005_01 12 the dma command packet pointer points to a 32-byte aligned address location in pci memory space that contains the next command packet to be loaded once the transfer currently programmed into the dma registers has been successfully completed. when it has been completed (or the dtbc register is zero when the go bit is set) the dma reads the 32-byte command packet from pci memory and executes the transfer it describes. once all the parameters associated with the transfer have been programmed (source/ destination addresses, transfer length and data widths, and if desired, linked lists enabled), the dma transfer is started by setting the go bit in the dgcs register. if dtbc=0, it checks the chain bit in the dgcs register and if that bit is cleared it assumes the transfer to have completed and stops. otherwise, if the chain bit is set, it loads into the dma registers the command packet pointed to by the dcpp register and initiates the transfer describe there. 1.3.2.6 error logging the universe ii has a number of register dedicated to error detection and logging, for errors on the pci bus l_cmderr and laerr are used while v_amerr and vaerr are used for the vmebus. the bits in the l_cmderr register are used for the following: cmderr logs command information for the transaction that caused the error l_stat - error is qualified with this bit. (status of error log) laerr is used to log the address of the errored transaction logged into the l_cmderr register. the bits in the v_amerr register are used for the following: amerr - vme bus am code error log v_stat - vme log status vaerr is used to log the vmebus address of the errored transaction logged into the v_amerr register. for further information on when data is logged to the error registers see the universe ii manual. 1.3.2.7 bi-mode when in bi-mode the universe ii is logically isolated from the vmebus and will allow only register accesses. a side effect of this is that all pci coupled transactions will be retried. no vme interrupts will be serviced by the universe ii, once the dma fifo fills/empties no more dma activity will occur.
universe ii debug and initialization notes 8091142_an005_01 13 bi-mode is set in the bi bit misc_ctl register - (0=universe ii not in bi-mode, 1=universe ii in bi-mode). the only traffic permitted is to universe ii registers either through configuration cycles, the pci register image, the vmebus register image, or cr/csr space. there are four ways to cause the universe ii to enter bi-mode. the universe ii is put into bi-mode: 1. if the bi-mode power-up option is selected 2. when sysrst* or rst# is asserted any time after the universe ii has been powered-up in bi-mode, 3. when vrirq# [1] is asserted, provided that the engbi bit in the misc_ctl register has been set, or 4. when the bi bit in the misc_ctl register is set. there are two ways to remove the universe ii from bi-mode: 1. power-up the universe ii with the bi-mode option off 2. clear the bi bit in the misc_ctl register, which will be effective only if the source of the bi-mode is no longer active. 1.3.2.8 timers the coupled window time in the lmisc register determines how long the universe ii will hold vmebus after performing a coupled read or write. 1.3.2.9 vme arbiter the universe ii can act as vmebus arbiter when it is in slot 1 as syscon. the bits associated with the arbiter are in the misc_ctl. the varb bits determine the arbitration mode: round robin or priority and the varbto bit determine the vmebus arbitration time-out. 1.3.2.10 sysfail if the sysfail bit in the vcsr_set register is read it return a 1 if vxsysfail is asserted and 0 otherwise. if a 1 is written to this bit then vxsysfail is asserted. 1.4 generating pci configuration cycles pci configuration cycles can be generated by accessing a vmebus slave image within the universe ii. 1.4.1 generating configuration type 0 cycles the universe ii asserts one of ad[31:11] on the pci bus to select a device during a configuration type 0 access. to perform a configuration type 0 cycle on the pci bus: program the las field of vsix_ctl for configuration space, program the vsix_bs, vsix_bd registers to a suitable value, program the vsix_to register to 0, and
universe ii debug and initialization notes 8091142_an005_01 14 program the bus_no field of the mast_ctl register to a value. perform a vmebus access where: ? va[7:2] identifies the pci register number (mapped directly to ad[7:2]) ? va[10:8] identifies the pci function number (mapped directly to ad[10:8]) ? va[15:11] selects the device on the pci bus (mapped to ad[31:12] according to table 2.2, ? va[23:16] matches the bus_no in mast_ctl register, and ? other address bits are irrelevant - they are not mapped to the pci bus.
universe ii debug and initialization notes 8091142_an005_01 15 table 8: pci address line asserted as a function of va[15:11] va[15:11] a a. the other values of va[15:11] are not defined and must not be used. pci address line asserted bb b. only one of ad[31:11] is asserted; the other address lines in ad[31:11] are negated 00000 11 00001 12 00010 13 00011 14 00100 15 00101 16 00110 17 00111 18 01000 19 01001 20 01010 21 01011 22 01100 23 01101 24 01110 25 01111 26 10000 27 10001 28 10010 29 10011 30 10100 31
universe ii debug and initialization notes 8091142_an005_01 16 1.4.2 generating configuration type 1 cycles to generate a configuration type 1 cycle on the vmebus: program las field of vsix_ctl to configuration space, program the vsix_bs, vsix_bd registers to some suitable value, program the vsix_to register to 0 and program the bus_no field of the mast_ctl register to some value. perform a vmebus access where: ? vmebus address[7:2] identifies the pci register number, ? vmebus address[10:8] identifies the pci function number, ? vmebus address[15:11] identifies the pci device number, ? vmebus address[23:16] does not match the bus_no in mast_ctl register, and ? vmebus address[31:24] are mapped directly through to the pci bus.

▲Up To Search▲

Price & Availability of CA91C142

	To Download CA91C142 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .